Conventionally, a Service Provider (SP) may have customers for network services which are located in another network domain. For example, a customer may be located in an Access Provider (AP) domain; the SP must reach the customer via equipment hosted by the AP, and the network services may include packet services. Conventionally, an SP must reach the customers with equipment that is hosted by the AP. For example, one type of equipment may include a Virtual Network Interface Device (vNID) such as described in the Metro Ethernet Forum (MEF, metroethernetforum.org) Technical Specification MEF 43 entitled “Virtual NID (vNID) Functionality for E-Access Services,” April, 2014, the contents of which are incorporated by reference. In such cases, the services offered to the customer may be limited by the capabilities of the particular equipment that has been deployed by the AP and cannot be easily changed by the SP. The SP may be able to configure some aspects of the equipment behavior using a Remote Management Interface (RMI), such as the speed or bandwidth profile to be selected for the user, but this is limited to the options that have been predefined for the equipment or the SP must contact the AP in order to get more significant changes made, adding delay and cost to the service. MEF 43 describes the present state-of-the-art for SP control of services offered to a remote user. MEF 43 describes a management interface between the SP and the vNID across a boundary between the AP and the SP, to configure a static set of objects supported by the vNID. However, MEF 43 is restricted to Ethernet (ETH) layer functions related to a MEF Service at a User-Network Interface (UNI) on the network side, i.e., an UNI-N (network side of UNI).
Software Defined Networking (SDN) is an emerging framework which includes a centralized control plane decoupled from the data plane. In SDN, network services are managed through abstraction of lower-level functionality by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). The SDN architecture is: (i) directly programmable: network control is directly programmable because it is decoupled from forwarding functions; (ii) agile: abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs; (iii) centrally managed: network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch; (iv) programmatically configured: SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software; and (v) open standards-based and vendor-neutral: when implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.
The components in SDN include an SDN application, an SDN controller, an SDN data path, a control to data plane interface, and northbound interfaces. SDN applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDN controller via the northbound interface (NBI). The SDN controller is a logically centralized entity in charge of (i) translating the requirements from the SDN application layer down to the SDN data paths and (ii) providing the SDN applications with an abstract view of the network (which may include statistics and events). The SDN datapath is a logical network device that exposes visibility and uncontended control over its advertised forwarding and data processing capabilities. The SDN CDPI is the interface defined between an SDN controller and an SDN data path, which provides at least (i) programmatic control of all forwarding operations, (ii) capabilities advertisement, (iii) statistics reporting, and (iv) event notification. SDN NBIs are interfaces between SDN applications and SDN controllers and typically provide abstract network views and enable direct expression of network behavior and requirements. Exemplary SDN protocols and the like include OpenFlow (www.opennetworking.org/sdn-resources/onf-specifications/openflow/), General Switch Management Protocol (GSMP) defined in RFC 3294 (June 2002), and Forwarding and Control Element Separation (ForCES) defined in RFC 5810 (March 2010), the contents of all are incorporated by reference herein.
SDN Controllers, SDN Southbound Interfaces, such as OpenFlow, support finer-grained control over the forwarding tables and packet or circuit processing done by a logical switch such as an OpenFlow Logical Switch (OLS) than vNID control in MEF 43. However, SDN control assumes that all devices are in a same domain, i.e., an SDN controller conventionally only controls switches in a single domain.
The Broadband Forum has a Technical Report TR-069 entitled “CPE WAN Management Protocol v.1.1,” December, 2007, the contents of which are incorporated by reference. TR-069 has specified remote configuration and service provisioning of a Customer Premises Equipment (CPE) along with communication with an Auto-Configuration Server. ETSI has published a Group Specification ETSI GS NFV 001 entitled “Network Functions Virtualization (NFC); Use Cases,” October, 2013, the contents of which are incorporated by reference. ETSI GS NFV 001 identifies Network Functions Virtualization Infrastructure (NFVI) as a service where virtual instances may be in the infrastructure of another provider.
Disadvantageously, present state of the art only allows the SP to configure a set of objects related only to a specific layer such as the ETH layer functions in a vNID (MEF 43) or the Asynchronous Transfer Mode (ATM) layer in a CPE (TR-069) in order to control the service offered to the user. Also, these have limited flexibility for the SP to change service characteristics without further involving the AP to modify or replace the equipment at the UNI. While SDN approaches such as OpenFlow offer much finer grained and more flexible control of the service, including adaptation from one layer or encapsulation to another, it is currently defined for a single domain only.